A thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler, which is typically a part of the operating system. The thread has a thread ID, a program counter, a register set, a stack, etc. to deal with a requested specific service, and shares other resources such as codes, data, files, etc. with other threads.
Conventional servers may create a thread whenever a request is received from a client, and this is a mechanism effective enough to deal with most tasks. However, in case of servers where connections and disconnections from clients occur very busily, as it takes a more time for such servers to create and remove threads than to deal with requests, the performance of the system may be degraded. Moreover, when the requests from the clients are rapidly increasing and the threads are created for the respective requests, thread scheduling is required to deal with the threads, and therefore, overhead time of the system may increase.
To solve such problems, methods of using a thread pool which includes a limited number of threads already created and does not remove executed threads to recycle the executed threads were suggested.
The thread pool, as a set of threads including at least one thread, recycles the executed threads by allocating them to other tasks, instead of removing them. More specifically, the thread pool may provide a specific thread to allow a specified task to be executed by a corresponding processor and then, if the processor completes the execution of the specific thread, after some waiting time, the thread pool may allow another tasks to be allocated to the specific thread.
The thread pool includes and manages information on the number of threads to be kept to the minimum (i.e., a minimum thread size) and information on the number of threads that can be created to the maximum (i.e., maximum thread size). But it is not easy to decide the minimum thread size and the maximum thread size for optimizing the performance of the server.
Most conventional methods may pre-set values of the minimum thread size and the maximum thread size depending on the number or types of service requests, measure the performance by using the pre-set values thereof and then determine optimal number of threads by referring to the measured performance. But since the conventional methods require more time while experiments have been made to accumulate the performance records and it is difficult to determine the minimum thread size or the maximum thread size properly under a rapidly changing web environment in real time, it is not easy to guarantee the accuracy with respect to the performance records.
Besides, there is another conventional method in which necessary threads are pre-created by predicting the number of necessary threads, but it has no great difference in performance from a still another method for creating threads after receiving a request, and it is also difficult to guarantee the accuracy of prediction due to the characteristics of the rapidly changing web environment.
Moreover, there is a still yet another method in which throughput is measured as amount of tasks processed per unit time and then the proper number of threads is determined by referring to the measured throughput, but since the throughput is also measured by using at least one thread, it is difficult to measure the throughput rapidly under the situation where tasks are rushed.
Accordingly, a new technology for enhancing the system efficiency by deciding optimal thread pool size dynamically under the rapidly changing web environment in real time is required.